…ocking

The mxqi keep-serving guard counted only nodes serving on the status
page and then assumed the node about to be taken down was one of them
(serving - 1 >= MXQI_MIN_UP). When every mxqi node already had mxqd
stopped or draining, none appeared on the page, so 'serving' was 0 and
the guard held forever, waiting for a node that could not return on its
own.

Only protect nodes that are actually serving: prefer an mxqi node that
is already down (rebooting it removes no interactive capacity), and
apply the keep-serving throttle only when the remaining candidates are
still serving.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

Replace the HTML scrape of the mxq server status page with a direct
query of the mxq_daemon table via /etc/mxq/mysql_ro.cnf. This is a
machine-readable, authoritative source and drops the curl dependency.

Take the newest daemon row per host and keep only daemons that are
actually accepting jobs (status 0 = idle, 10 = running); a draining
daemon (status 200) or a gone one (>= 250) is left out, so the
'serving' notion the mxqi keep-serving guard relies on stays correct.
Rows not refreshed within DB_FRESH_MIN minutes are ignored so a daemon
that vanished without recording a stop is not mistaken for live.

Skip a poll when the query fails instead of acting on an empty result,
which would otherwise look like 'nothing is serving' and could wrongly
free the mxqi guard.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

--tag takes any hostconfig tag, and non-cluster nodes have tags too, but so
far every selected node was treated as an mxqd node: it got the one-time
'mxqdctl-hostconfig start' unit, and the detached script ran

    mxqdctl-hostconfig stop
    while pgrep -x mxqd >/dev/null 2>&1; do sleep 10; done

which on a node without mxqd is pointless (mxqdctl-hostconfig is not even
installed there, so 'set -e' aborts the script before mxgrub and the node is
never rebooted), and the load-aware pacing derived from the mxq database is
meaningless for such nodes as well.

Read the mxqd nodes from /etc/hostconfig and split the work into three pools:
the load-paced batch mxqd nodes, the throttled mxqi nodes, and the nodes
without mxqd. The latter are rebooted strictly one after another (PLAIN_MAX,
default 1, --plain-max/--no-plain to change), and their remote script is just
'mxgrub <label>' plus the reboot - no drain, no start unit. A run that selects
no mxqd node does not query the mxq database at all.

If /etc/hostconfig lists no mxqd node the tool now refuses to run instead of
silently classifying every node as mxqd-free and rebooting busy nodes without
draining them; --mxqd-nodes overrides the detection ('' means none of them).

Assisted-by: Claude Opus 5

Selecting a single serving mxqi node made the tool loop forever:

    mxrolling-reboot -H stairwaytoheaven mariux-6.18.42-494
    mxqi: holding (1 serving; keep >= 1) - waiting for an mxqi node to return

MXQI_ALL held the mxqi nodes intersected with the selection, and the
keep-serving guard counted serving nodes over that intersection only. With
one mxqi node selected, serving - 1 = 0 never reaches MXQI_MIN_UP, so the
node was never taken down, even though the other mxqi nodes were up and
serving interactive sessions all along.

Count over every mxqi node of the cluster instead and restrict only the
upgrade list to the selection: MXQI_ALL is now the full set, MXQI_SEL the
selected ones. The guard still holds when taking the node down would really
drop the cluster below MXQI_MIN_UP serving mxqi nodes.

Assisted-by: Claude Opus 5

The batch concurrency limit was derived from a cluster-wide idle count read
from the mxq database, so a narrow selection was paced by nodes the run never
touches:

  $ ./mxrolling-reboot --dry-run -H a,b,c,d mariux-6.12.98-492
  DRY-RUN: 50 idle nodes now -> would upgrade up to 25 batch node(s) at a time

Count the idle nodes over the batch pool instead, i.e. over the selected mxqd
nodes that are not mxqi nodes (BATCH_ALL), so the limit reflects the pool it
paces:

  DRY-RUN: 2 of the 4 selected batch node(s) idle now -> would upgrade up to 1
  at a time

A full-cluster run is unchanged except that the mxqi nodes no longer count
towards the batch limit - they have their own pool and pacing. The two copies
of the "how many at a time" arithmetic and of the status parsing move into
batch_limit(), batch_idle() and load_status().

Assisted-by: Claude Opus 5 (claude-opus-5)